Access was restored by locating and supplying the device‑specific 48‑digit BitLocker recovery key that matched the Recovery Key ID shown at the pre‑boot prompt. Keys were obtained from inventory/MDM records, the user’s Microsoft account Devices/recovery page, Azure AD/Entra recovery listings (aka.ms/aadrecoverykey), recovery‑ID ↔ serial mappings, or from the asset owner/colleague; Intune sometimes showed no stored key. When a device serial was not available, technicians used an attached screenshot of the pre‑boot prompt to match the Recovery Key ID in portals. Technicians verified the portal‑selected device against the Recovery Key ID and asset serial when an initial or outdated key had been retrieved. Keys were transmitted using observed secure channels — examples included Microsoft Teams (desktop and mobile), Outlook/secure mail apps, SafeApp/SafeLink single‑use secure links, and in‑person handoffs; in several incidents a full 48‑digit key was present in the ticket text (an observed practice distinct from the secure‑channel examples). Where mobile or secure‑mail UIs clipped or truncated digits, agents retried the recovery page, used alternate secure channels and re‑sent missing final digits. For pre‑boot prompts that did not accept normal input, access was restored by confirming the recovery field had focus, using the numeric keypad or function‑key number mapping, trying an external USB keyboard, or — on affected Lenovo models — performing the hardware reset via the underside pinhole; after input was restored the provided 48‑digit key unlocked the device. A recorded UI symptom where the key could be entered but the recovery UI’s Continue button remained disabled was resolved by re‑sending the key via an alternate secure channel and providing real‑time phone support to guide retries. Several incidents were attributed to faulty Microsoft/Windows updates; these rollouts were paused or the problematic update was blocked, many devices showed an update rollback or completed Windows Automatic Repair after unlocking, and some tickets were escalated to specialist teams preparing corrected updates. A small number of cases were transient: a full power‑off (cold boot) and then power‑on allowed the device to boot normally without requiring the recovery key. Persistent or recurrent re‑locking and boot‑loop cases required replacement hardware or reimaging and a review of account provisioning; at least one device was removed from Entra/Azure AD to disassociate it from a former work account after the key was recovered.

Support confirmed that USB mass‑storage access and/or USB ports had been centrally disabled on Windows 11 corporate devices by Endpoint Management in coordination with Security, and that local IT could not perform individual permanent unlocks. Support provided alternative file‑transfer options and procedures such as syncing required files via OneDrive from a private PC, using SharePoint or SAFE‑App, leveraging the IU Research Cloud, or using network printing where appropriate. In at least one case a user placed files into OneDrive from a private PC, allowed them to sync to the Windows 11 notebook, and confirmed that this restored access to the files.

SAR guidance was followed and targeted searches were performed across all known corporate and third‑party systems: email inboxes and deleted items, SharePoint tenant content, student‑records systems (CARE, myCampus, OASIS), learning platforms (Brightspace/D2L), payment/refund records, complaints and investigation files, Minerva handover records, and third‑party or personal cloud accounts (for example personal OneDrive and OneNote). Where an initial extraction was blocked due to missing or insufficient SAR information, the SAR was updated and extraction from the relevant system (for example OASIS) proceeded as usual. Brightspace/D2L data required escalation to a named liaison who could engage D2L to confirm available exports and supply data. Where personal or external accounts held data, written consent from the data subject was obtained and evidence of consent was retained before security‑assisted access. The security team performed assisted access and examined live files plus deleted‑item/restore points; irrecoverable items were documented (for example permanently emptied OneDrive files) and any recoverable items were collated. A consolidated data package or a nil return was prepared and submitted within the SAR deadline. For student login/authentication discrepancies (for example CARE not reflecting myCampus authentication activity), investigations were routed to the Study‑Support/myCampus team (techsupport@iu.org).

Targeted anonymisation and selective deletions were performed across implicated systems while preserving records required by statutory retention. Oasis student records were anonymised where full deletion was not permitted. SQL CRM personal identifiers were removed or obfuscated in contact, contact_address, contact_private, contact_private_history, consent and consent_history when applicable. Scanned-document tables (scanned_document, scanned_document_link) had identifying metadata or file-level identifiers redacted. Quercus entries were edited to remove email, phone and address fields where requested while retaining non-identifying residency data (postcode/country) when appropriate. Term-time and permanent addresses were handled per request subject to each system’s retention rules. Misattributed reasonable-adjustment and disability-support entries (and their history) were removed from incorrect contacts while original evidence remained linked to the correct student. When an application enforced a field (for example surname) values were obfuscated or replaced with an initial when permitted; application constraints were recorded on the student record and communicated to the requester when modification was prevented. CARE and myCampus account requests were investigated for lifecycle and upstream-integration causes: accounts sourced from Salesforce or created for prospective students were removed or anonymised when no lawful basis to retain data existed; where contacts were transferred from Salesforce, deletions required coordination with the owning CRM/CARE admin or Study-Support because submitters frequently lacked deletion permissions. Graduated-student queries about unexpectedly active accounts were resolved by deactivating or removing the account and documenting the cause (lifecycle/process mismatch) on the record. Third-party, external or vendor-held records were identified and recorded when outside the actioned scope; where downstream/third-party systems were within support scope (for example Dotdigital, Arlo, Brightspace) records were located using platform-specific identifiers (e.g. DotdigitalContactId, ArloContactId, BrightspaceUserId) and personal data was erased when no lawful basis to retain it existed. Identifiers used to locate records typically included matriculation number (MNR), GUID, email, address and platform‑specific IDs; all completed changes and any constraints or referrals were recorded on the student record and tickets were closed after anonymisation, selective deletion or formal referral to Study-Support/CRM teams.

An administrator removed the phone number from the SharePoint User Profile record (SharePoint Admin Center → More features → User Profiles → Manage User Profiles → Edit-Profile) and used the hidden save control to commit the change. This was performed when the number appeared only in SharePoint user profiles or when users lacked permission to update their own profile. The administrator informed the user that profile propagation across SharePoint, Outlook and Teams required up to 1–3 days; after propagation the phone number no longer appeared and external calls ceased.

A governance initiative was started to remove unused reports, datasets and workspaces, consolidate redundant reports, and introduce monitoring for resource usage and failed refreshes; documentation and backup arrangements were also identified. Stakeholder concerns about non-anonymised usage metrics, tenant data residency (EU) and vendor contract/licensing terms were recorded and escalated to procurement and legal for review.

Investigations found multiple exposure vectors and each incident was handled according to the data type and impact (information‑exposure or PCI). Screenshots and images that embedded tokens or links were traced to their origin and removed or visually redacted; sensitive links and keys discovered in tickets or images were rotated or replaced. Legacy public pages and iframe‑embedded content that exposed staff contact details were located via search, the embedding method was confirmed, and community content was edited to remove contact PII and reference the contact form URL so the data was no longer indexable. Application logging and retention reviews identified Oasis test‑mode PANs written to server logs (\ifslearning.com\ifs2000\cantapps\logs\commidea) and a Missed‑Transactions.xlsx spreadsheet on the Professional Education SharePoint site; the identified log files and the SharePoint spreadsheet were removed and the incidents were recorded for PCI/retention review. An OpenAI API key posted in cleartext within a support ticket was replaced by creating a new key in the OpenAI account; a separate chatbot integration noted an Azure OpenAI key recorded as missing/unsaved during troubleshooting and was documented. A security review confirmed Okta accessToken and idToken were stored in localStorage (key: "okta-token-storage") and were readable by a proof‑of‑concept Chrome extension that injected code into an open okta.iu.org tab; this client‑side exposure was documented as a token‑theft risk. Reports that internal Teams meeting invites or emails had been forwarded to private external addresses were triaged and staff were advised that forwarding internal meeting or message content to private email accounts bypassed internal controls; reporters acknowledged the guidance. A separate incident of misdirected exam‑registration emails was traced to an overwritten Care configuration setting during a changeover; the incorrect setting was restored and Care email routing was corrected so system‑generated registration messages were no longer sent to unintended recipients. The consolidated outcomes recorded targeted removal or redaction of exposed artifacts, deletion of improperly retained logs/spreadsheets, secret replacement or rotation where keys were exposed, PCI incident handling where cardholder data was found, documentation of client‑side token exposure risk, and correction of application configuration that caused misdelivered messages.

IT confirmed that a Microsoft Form set to 'anyone can respond' without collecting identifying fields did not present a way for IT to derive respondent identities from the form submissions; form owners only saw the submitted answers. The absence of the 'one response per person' option indicated that identity was not captured by Forms. IT explained that, in theory, re‑identification could be attempted with browser/network metadata and cooperation from Microsoft or ISPs, but IT did not have access to those data. IT also raised awareness that storage or processing outside the form (for example, if responses were exported to SharePoint or correlated with other data) or inclusion of identifying questions could enable re‑identification, and clarified these limits to the requester.

Incidents were reported to local law enforcement and corporate IT verified whether corporate data (OneDrive) resided on the device. Asset and procurement checks were performed across ABM, ASM, procurement records (Contabo), and inventory spreadsheets; when devices could not be found in those systems they were treated as unmanaged. Microsoft Intune remote‑wipe commands and device isolation were initiated; wipes for offline devices remained queued until the device checked in. Windows devices were confirmed to have BitLocker protecting local drives; Apple devices that were not enrolled in Jamf/ABM/ASM could not be locked or tracked. Users were instructed to file the data‑protection incident form (Datenschutzvorfall) and to rotate passwords for affected accounts as a precaution. Sign‑in logs and last‑seen timestamps from Microsoft Defender, Entra‑ID/Azure AD and Okta were reviewed to assess recent activity; account access was contained by revoking sign‑in sessions, temporarily disabling or disabling/reactivating accounts, and rotating credentials where appropriate. For stolen or recovered phones, staff advised preserving device state for police (avoiding factory resets) until authorities had taken custody. Where Okta Verify did not recognize an MFA key on a replacement device, Okta authentication was reset and MFA was re‑enrolled (activation codes/regeneration of factors were used as required). Replacement hardware was procured, shipped, and recorded in Inventory360 and IT service records; all actions were documented in the data‑protection form and IT service portal.

The issue was resolved by addressing both tenant-side and vendor-side access. Tenant-side actions removed the application's access by deleting the service principal and revoking OAuth/admin consent in Azure AD/Entra (via myapps.microsoft.com), clearing user-level app authorisations, and unlinking affected user accounts. The app was explicitly blocked in the Teams admin center and a Teams app permission policy that blocked the app was applied tenant-wide; the meeting policy was temporarily adjusted so external apps/guests waited in the lobby while changes propagated. Where the vendor had automatically created an account (Fireflies) the vendor-side account was deleted and the Fireflies/“Fred” app tile was removed/uninstalled from Teams Apps. After these combined tenant- and vendor-side actions the assistant stopped auto-joining meetings and producing recordings/summaries.

The data protection/privacy team was consulted and issued a definitive negative ruling: IU‑issued laptops must not be used for work at other employers, and IU work must not be performed on devices issued by other employers. This decision was communicated to the requester and the ticket was closed.

Support clarified that an Apple ID is a private account used only for Apple services (App Store, iCloud backups, iCloud Mail, device‑level sync) and that personal data synced via Apple services was not integrated into, pushed to, or accessible from institutional applications or servers. The recurring ‘Apple Federation Switch’ reminders and other Apple notifications were generated by Apple and an unused or fake iCloud address on a managed device had no effect on institutional services. For password synchronization, support confirmed that iCloud Keychain/password sync was not available on managed devices because of company policy; corporate cross‑device password synchronization was handled via 1Password. The admin was unable to enable iCloud Keychain for that user for policy reasons, and the user was routed to the organization’s 1Password deployment for cross‑device password access.

Requests for vendor DPAs, processing descriptions and clarifications were escalated to vendor contacts and internal contract owners, and received documentation or vendor attestations were recorded and delivered to requesters and to Legal/Works Council for review. For AvePoint the vendor supplied a DPA, a data protection concept and a vendor processing description by email; those items were forwarded for Works Council review. For Microsoft‑related requests the team searched internal contract repositories (Workday and a shared SharePoint store), repeatedly followed up with the named Microsoft contact when residency, contractual clauses or AI/data‑use details were unclear, and involved procurement, Legal and contract owners to obtain contractual texts and processing descriptions; the Enterprise Online Services DPA and vendor processing descriptions were recorded. The team documented vendor statements about server locations, encryption in transit and at rest, patching/security updates, retention/automatic deletion concepts, and auditing/logging capabilities, and captured vendor attestations or contractual clauses about whether product features or Copilot could access or be used to train models; those materials and Legal’s conclusions were handed to Works Council. For external import/sync incidents (for example Handshake) the vendor paused an automatic import after private/non‑IU email addresses were detected and requested explicit approval; the team reviewed vendor processing documentation, engaged Data Protection/Legal and Works Council to determine permissibility, recorded the vendor request and the approval/decision, and captured any changes to sync configuration or data exports. A security review of CodeTwo Email Signatures 365 identified a control‑plane risk where compromise of the signature‑management environment could have allowed manipulation of signatures across all organizational email; the team documented the mass‑mail compromise risk, recorded ambiguity about operational responsibility and account lifecycle for the SaaS environment, reviewed SSO/2FA and account/permission controls, and recorded the recommendation and rationale to prefer Outlook client‑side signature mode over cloud/server‑side or combo modes. For services without published data‑protection policies or unspecified storage locations (for example Microsoft Sway) support recorded the restriction and advised requesters to escalate to the data protection team (datenschutz@iu.org) with usage details for an official decision. When internal contract copies were missing or vendor responses were delayed the lack of documentation and the escalation path were recorded and communicated to stakeholders. In the Hugging Face case the team confirmed that an Enterprise account offering existed, reviewed the vendor’s GDPR/compliance materials and the available DPA draft, and escalated the absence of a signed DPA to procurement and Legal to obtain contract signatures and to confirm SSO integration, private‑repository support, and available edu‑licensing or expedited onboarding options; those findings and any vendor attestations were recorded and delivered to the requestor and to Legal/Works Council. All received DPAs, vendor processing descriptions and vendor attestations were stored in the contract/document repository and logged alongside the decision or recommendation provided to the requester.

Affected Microsoft Teams and their corresponding Microsoft 365 Groups — including email-enabled groups visible in Exchange Online — were reclassified to the user-requested sensitivity/access categories. Reclassification was performed using the Microsoft Teams Admin Center and, where required for directory/email properties, the Microsoft 365/Azure AD admin portal. Automation tooling was used to apply the new classification values in bulk, to update email-enabled group addresses, and to verify the changes across the listed groups. Classification values were changed from prior states (for example 'Unmanaged / Students only') to the requested targets (for example 'Confidential / Employees only', 'Learning / Employees and students', 'Trusted / Employees and trusted guests'), and automation was used to log progress and post status/comments via Automation for Jira during the run.

Support traced the message flow (Amazon SES → Exchange Online) and used message traces/audit logs to identify that a Microsoft 365 group had an address matching the automated sender, which caused auto‑replies to be delivered to group members in addition to the intended destination. The findings (message trace details, implicated group identity, and delivery duplicates) were documented and communicated to the requester and relevant mailbox/group owners for remediation and follow‑up.

The registrations data was bulk-adjusted so that expiry dates did not extend beyond the official withdrawal cutoff. The bulk-update approach was aligned to the withdrawal cutoff rather than the requester’s earlier date to avoid prematurely truncating students who were due to transfer via the CeMAP/FSRE process on 13 January 2026. RRMP and the registration database were synchronized after the change, and Pearson exam booking data was checked to confirm no bookings existed beyond the cutoff.

Two distinct but related cases were handled. For a one-time secure delivery of a ~600 MB confidential dataset to external counsel, the requester uploaded the files to the Safe Portal and granted retrieval access; the lawyer retrieved the documents before the deadline and the Safe Portal was confirmed suitable for that file size and sensitivity level. For a collaborative research scenario where the user required a GDPR-compliant shared platform with an external university and their previously used academic-cloud provider did not list IU, support first clarified whether the dataset needed to be hosted on IU systems. Support then recommended two practical options: have the external partner host the dataset and grant the IU user access, or use an IU-hosted GDPR-compliant service (for example, Research-Cloud or an IU shared drive/folder configured for external collaboration). The guidance resolved the immediate compliance and access uncertainty by identifying an external-hosting shortcut and an IU-hosted alternative for joint storage, editing, and analysis.

The request was forwarded to the MyCampus specialist team and the requester was informed that the topic was already covered in two existing tickets. The specialist team requested the current/updated privacy policy documents (preferably via Teams) and the duplicate ticket was closed while follow-up continued on the existing tickets.

Support clarified that the appropriate transfer tooling depended on the official confidentiality classification (VS‑NfD, VS‑Vertraulich, Geheim, Streng Geheim) and identified BSI‑approved options (including GnuPG and VS‑Desktop) as candidates. The case was escalated to the CISO/consulting process to agree the exact transfer method and handling controls with the LKA. Physical‑media constraints (e.g., absence of local CD drives) and secure-read requirements were highlighted so the delivering party and CISO could arrange an acceptable media format and secure workstation for reading.

Investigation found the embedded signature protection had ceased working and an expired/invalid signing certificate was suspected. HR approved the remediation, accounts were provisioned and AdobeSign access was granted to the responsible team, and the qualified electronic signing process was re‑established using the organisation's authorised AdobeSign credentials so that subsequent PDFs again carried enforceable signature protection.

The request was forwarded to the applications team and Camtasia (TechSmith) was identified as a tool already used in the organisation that supports pixelation/blur for video and can be used to mask moving elements. A TechSmith knowledge article explaining how to pixelate/blur and track faces/regions in video was shared and a follow‑up meeting was offered to evaluate Camtasia against the specific production requirements.

Investigation established that Microsoft did not permit replacing or editing the standard Teams recording-start popup text; the only configurable element on that popup was the appended privacy/info link via Microsoft 365 Admin Center (Settings > Security & Privacy > PrivacyProfile). Administrators set that privacy/info link to point to the institution’s mycampus privacy/info page containing the required German and English notice. Stakeholders additionally requested a documented consent mechanism, advance notification via meeting invitations, and the ability to prevent camera/microphone use until consent was granted. Those requirements could not be satisfied by the Teams recording-start popup and, after evaluating related components (calendar invitations, Azure AD dynamic groups, Teams meeting policies, Engagement Report, and the Workday→Okta→AAD provisioning chain), no built-in Teams/Azure AD feature was found to capture documented consent or to block camera/microphone prior to consent. Compliance/legal were informed and the complaint process with the regulator was pursued; no change to the Microsoft-supplied popup wording or behavior was possible.

Support documented local storage options that remained outside OneDrive/SharePoint sync and confirmed hosting and residency information for institutional services. For Windows 10, folders created directly under the C:\ root were validated as not enrolled in OneDrive/SharePoint sync and therefore remained local and excluded from Copilot/SharePoint indexing. For Windows 11, an isolated DevDrive was provided to researchers on request and documented as an unsynchronised option. Infra confirmed the Research Cloud (nextCloud) instance was hosted on a dedicated Azure server and support collected contextual details (data types, sensitivity classification, retention/sharing requirements, and expected access model) needed to assess GDPR suitability. For online interviews collecting highly confidential personal accounts, support recommended using Microsoft Teams because its servers were hosted in Europe, providing a stronger data‑residency basis than Zoom; a consultation to review meeting configuration and protections was offered and arranged. The combined actions—documenting unsynchronised local storage, confirming Research Cloud hosting and collecting assessment context, and recommending EU‑hosted conferencing for sensitive interviews—addressed user uncertainty about cloud exposure and provided concrete inputs for formal suitability assessments.

For the iu-studierfaehigkeit.de case, teams confirmed that domain, DNS, webspace and TLS certificate management were controlled by the external provider Apelio; the named project contact was instructed to authorize Apelio to perform the renewal and installation, and Apelio renewed the certificate ahead of expiry. For the ConnectedWare report (cw.iubh.de), the login page was found to be served over plain HTTP; the issue was escalated to the ConnectedWare service/vendor and recorded as vendor‑handled, but the ticket contained no documented technical steps (such as enabling TLS, installing a certificate, or enforcing HTTPS). The consolidated record therefore captures (a) instances where third‑party responsibility was identified and the vendor performed a certificate renewal, and (b) instances where remediation was delegated to an external vendor without documented implementation details.

Legal and data‑protection advisers concluded that moving from third‑party analytics to in‑house tracking did not remove GDPR obligations. They assessed that behaviour logs which could be linked to individuals or used for profiling remained personal data; therefore a lawful basis was required (consent or a documented legitimate‑interest assessment where appropriate), privacy notices and purpose limitations needed updating, and subject‑rights processes (access, deletion) and retention/deletion controls had to be implemented. Advisers also recommended considering a DPIA where profiling or large‑scale behavioural processing was planned and ensuring any cloud storage (for example AWS DWH) had appropriate data‑processing arrangements.

Investigations found two root mechanisms that caused cross‑account personal‑data overwrites: erroneous Salesforce account‑merge operations and integration‑driven updates from Arlo to OASIS/myLIBF/Enquiry that mis‑matched person records. Affected student accounts were manually cleaned and untangled: Salesforce master/study profiles were corrected and corresponding entries in Care, Epos/MC and myLIBF/OASIS/Enquiry were reconciled so each student had the correct profile and study/master data. The Arlo/OASIS update on 8 Feb 2024 was identified as having been applied via the integration and LW history contained no explanatory entries for those changes. IT security and the named application owners were consulted for context, affected users were notified, a documentation ticket was created on the CYB board, and remediation and follow‑up work were prioritised with the operations lead. The fix therefore combined record restoration across affected systems, integration‑flow investigation to identify where person‑matching or merge logic had failed, and coordination with security and application owners for notifications and tracking.

Support performed an inventory check of the Confluence environment and confirmed that no PII‑protection app or related software was installed. The requester was informed of this status.

Support did not access or copy the employee's personal files due to organisational data‑protection and privacy rules and the absence of explicit owner consent. The requestor was informed that explicit consent or a formal authorised data‑access approval would be required before support could move or reassign the owner's personal files or change data sources.